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CONTROL METHOD AND APPARATUS FOR TESTING OF MULTIPLE 
PROCESSOR INTEGRATED CIRCUITS AND OTHER DIGITAL SYSTEMS 



5 Field of the Invention 

The present invention relates generally to integrated circuits and other types of digital 
systems, and more particularly to techniques for testing such systems. 

Background of the Invention 

1 0 A well-known standard for use in testing integrated circuits and other types of digital systems 

has been developed by the Joint Test Action Group (JTAG) and is defined in Institute of Electrical 
i<n and Electronics Engineers (IEEE) Standard 1 149.1, "IEEE Standard Test Access Port and Boundary 

*S Scan Architecture," IEEE, New York, NY, October, 1 993, which is incorporated by reference herein. 

5.1 I 

i£ For example, in the context of an integrated circuit, the IEEE 1 149. 1 standard defines test logic that 

:~ 15 can be included in an integrated circuit to provide standardized approaches to testing the 
in interconnections between integrated circuits once they have been assembled onto a printed circuit 

board or other substrate, testing the integrated circuit itself, and observing or modifying circuit 
^ activity during normal circuit operation. The test logic includes a boundary-scan register as well as 

ig other elements and is accessible through a Test Access Port (TAP) associated with the integrated 

j~ 20 circuit. The test logic allows test instructions and associated test data to be fed into the integrated 
w circuit, and allows the results of execution of the instructions to be subsequently read out. All 

information, i.e., test instructions, test data and test results, are communicated in a serial format. The 
integrated circuit test process is also commonly referred to as "debugging." 

Many recently-developed integrated circuits include multiple processors configured to 
25 implement a variety of so-called "system on a chip" solutions. The processor cores may be 
homogeneous, i.e., have the same processor architecture, or heterogeneous, i.e., have different 
processor architectures. The higher levels of integration associated with such multiple processor 
devices generally require additional package input/output (I/O) capacity, i.e., additional package pins 
and associated internal bonding pads, wiring etc. However, this requirement is in conflict with other 
30 requirements, such as portable operation, that generally require lower power and thus a lower 
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package I/O capacity. As a result, it is important that the integrated circuit test functions utilize as 
few pins as possible. 

The above-described IEEE 1149.1 standard has been used successfully to minimize I/O 
capacity requirements for debug access to integrated circuits with a single processor core or multiple 
homogeneous processor cores on the same scan chain. 

For example, a conventional approach to debugging of an integrated circuit with multiple 
homogeneous processors is described in L. Goudge, "Debugging Embedded Systems " ARM White 
Paper, www.arm.com, 1998. In this approach, if a user wishes to examine the state of more than one 
processor during a debugging session, then this may be achieved synchronously by setting up "debug 
halt" conditions independently within each processor while the system is running. Through use of 
the TAP controller state machine, all of the processors may then be stopped simultaneously. 
Similarly, at the end of the debugging session, "debug restart" conditions may be set up in each 
processor and again through use of the state machine, the processors may be restarted 
simultaneously. This approach requires that all of the processors be homogeneous, and all of the 
processors must be involved in the condition setting in order to provide the synchronous stopping 
and restarting. 

Another conventional approach for IEEE 1149.1 testing of an integrated circuit with 
homogeneous processors is the ScanProgrammer from ASSET InterTech, www.asset-intertech.com. 
This approach uses a single database that is loaded with Serial Vector Format (SVF) data to 
assemble scans for an IEEE 1 149.1 scan chain. 

Yet another known approach is the Global Embedded Processor Debug Interface Standard 
(GEPDIS), www.ieee-isto.org/Nexus5001, which describes the Nexus 5001 Forum™ Standard for 
a global embedded processor debug interface. This is an open industry standard that provides a 
general-purpose interface for the software development and debug of embedded processors. 

A number of significant problems arise in the application of the IEEE 1 149.1 standard to 
integrated circuits and other types of digital systems which include multiple heterogeneous 
processors. For example, conventional application of the IEEE 1149.1 standard to multiple 
heterogeneous processors often requires that a TAP controller for one or more of the processors be 
redesigned to support asynchronous control. This may require modifications of components not 
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designed to be easily modified or tested. Other conventional approaches may require special 
hardware to mediate access to multiple TAP controllers in a manner that often violates the IEEE 
1 149.1 standard and does not easily allow for synchronous control of the multiple processors. 

A possible software approach to the problems associated with testing multiple heterogeneous 
5 processors is to build a debugger that treats the target system as a single device and merges stand- 
alone debug systems for all of the devices to be controlled. Unfortunately, the drawbacks of this 
approach are numerous. For example, the source code for each debug system must be modified, and 
this source code can be difficult to access. In addition, the resulting debugger supports only one or 
at most a handful of combinations of devices. Furthermore, upgrades to the stand-alone debug 
1 0 systems must be laboriously reintegrated into the merged debugger. 

In view of the foregoing, it is apparent that a need exists for an improved control mechanism 

13 

J for use in testing of integrated circuits and other types of digital systems which incorporate multiple 

:;:J and possibly heterogenous processors. 

i.y 

Is 15 Summary of the Invention 

'"^ The present invention provides a control mechanism for use in testing of integrated circuits 

□ and other digital systems which incorporate multiple processors. ____ 
j*? In accordance with the invention, the control mechanism dynamically defines a group of 
S processors subject to common control, e.g., at the direction of a debugger program associated with 

□ 20 a debug client. The control mechanism then receives one or more commands for each of the 

processors in the group, and delays issuance of at least a subset of the commands for the group until 
a designated group scan command is received for each of the processors in the group. 

The control mechanism may be in the form of a software-implemented chain manager which 
provides the above-noted group definition, command receipt and issuance delay operations, and 
25 subsequently delivers the commands as a single serial bit stream to an IEEE 1 149. 1 hardware scan 
chain associated with the processors. The control mechanism can provide synchronous control for 
a group of homogeneous processors, or pseudo-synchronous control for a group of heterogeneous 
processors. 
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As noted previously, the group of processors may be defined in response to a group request 
received from a debugger. The chain manager in this case defines the group by, e.g., establishing 
a group identifier for the group, storing the group identifier and a size of the group, and returning 
the group identifier to the debugger. 

The test commands for each of the processors in a given group may be generated by a Test 
Access Port (TAP) manager associated with the corresponding processor. Each processor and its 
corresponding TAP manager is a member of only one group at a given point in time, but can be 
members of different groups of processors at different points in time. 

The control mechanism, which may be advantageously implemented in software, allows the 
multiple processors to perform synchronous or pseudo-synchronous operations without requiring 
excessive coupling between individual processor debug systems as in the above-described 
conventional approaches. In addition, the processor grouping can be altered dynamically to allow 
for multiple groups of processors on the same scan chain and the alterations of these groups during 
a single debugging session. The control mechanism of the present invention is thus reusable for 
different numbers and arrangements of processors, and is also scalable for use with any desired 
number of processors. 

Brief Description of the Drawings 

FIG. 1 shows an illustrative embodiment of a system which incorporates a mechanism for 
control of multiple processors in accordance with the invention. 

FIG. 2 is a diagram showing an example of the processing of test commands in the 
illustrative embodiment of the invention. 

FIG. 3 is a functional diagram illustrating the operation of the FIG. 1 control mechanism. 

FIG. 4 is a timing diagram for a particular example implementation of a control mechanism 
in accordance with the invention. 

Detailed Description of the Invention 

The present invention will be illustrated herein in the context of a exemplary multiple 
processor system. It should be understood that the invention is more generally applicable to any type 
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of digital system which includes two or more processors. The term "processor" as used herein is 
intended to include not only programmable processors such as microprocessors or digital signal 
processors (DSPs), but more generally any type of digital logic function that may be controlled by 
a scan chain. The term "digital system" is intended to include a single integrated circuit, a set of two 
or more integrated circuits, or other types and arrangements of devices which collectively 
incorporate two or more processors. 

FIG. 1 shows a multiple processor test system 100 which includes a debugger 102, a 
scheduler 1 04, and a chain manager 1 06. Coupled between the scheduler 1 04 and the chain manager 
106 is a set of Test Access Port (TAP) managers 108X, 108Y and 108Z, each associated with a 
corresponding one of three processors X, Y and Z. The system 100 further includes a Joint Test 
Action Group (JTAG) hardware scan chain 1 10 configured in accordance with the above-described 
IEEE 1 149. 1 standard. The scan chain 1 10 is coupled to a series connection of the three processors 
X, Y and Z, also denoted as elements 112X, 112Y and 112Z, respectively, in the figure. The 
processors X, Y and Z and the corresponding scan chain 1 10 are part of one or more integrated 
circuits or another type of digital system to be tested. The chain manager 106 is also referred to 
herein as a JTAG chain manager. 

The scheduler 104 supplies debug commands for the processors X, Y and Z to the 
corresponding TAP managers 108X, 108Y and 108Z, respectively. The TAP managers generate 
IEEE 1 149.1 commands for each of the processors, and these commands are supplied along with 
TAP data for each of the processors to the chain manager 106. 

The operation of the system 100 will now be described for a given test configuration 
involving a designated group of the multiple processors. The debugger 102 via the scheduler 104 
asks the chain manager 106 for a group identifier (GROUP ID) for a group of known size. A 
particular member of a group refers generally to one of the processors and its corresponding TAP 
manager. The chain manager 1 06 issues a GROUP ID and stores that GROUP ED as well as the size 
of the group. This GROUP ID is passed back to the debugger 102. Each of the TAP managers 
1 08X, 1 08 Y and 108Z includes a device-specific program for its corresponding processor, and issues 
one or more IEEE 1 149.1 scan commands ending with a group scan command which may be, e.g., 
an instruction register (IR) command and/or a data register (DR) command. 
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A group scan command in the illustrative embodiment refers generally to a final JTAG scan 
command that occurs before a desired synchronous or pseudo-synchronous behavior. The group 
scan command generated by one of the TAP managers in a group is delayed by the chain manager 
106 until the TAP managers for all other group members issue a group scan command. The 
5 individual commands of the groups are then merged, and synchronously and simultaneously scanned 
into the scan chain 1 10 by the chain manager 106. 

The chain manager 106 thus delays the issuance of the group scan commands for the 
members of the group until all members of the group arrive at an equivalent state in their control 
sequences. 

10 It is important to note that the individual TAP managers have no knowledge of the group 

size. The group size in the illustrative embodiment of FIG. 1 may be one, two or three. Although 
only three processors are shown in this example, it should be understood that the control mechanism 
j;0 of the invention may be applied to any desired number of processors in other embodiments. 

W Moreover, the processors in a given group may be homogeneous or heterogeneous. Group 

ifj 1 5 membership is dynamic, and each processor and its corresponding TAP manager may be a member 
*~ 4 of different groups at different times. Each processor and its corresponding TAP Manager is only 

IS a member of one group at a time. 

3 ff 

i';! The scheduler 104 instantiates a TAP Manager for each physical processor that is being 

9 tested on the single IEEE 1 149.1 hardware scan chain 1 10. The scan chain 1 10 may include other 

O 20 processors that are not being tested. The debugger 102 sends to the scheduler 104 commands that 
carry the above-noted GROUP ID. The scheduler 1 04 removes the GROUP ID from a TAP request 
going to one of the TAP managers and passes the GROUP ID to the chain manager 1 06. The chain 
manager 106 then stores the GROUP ID in a TAP Data class hidden from the corresponding TAP 
manager. The chain manager 106 is preloaded with the group size but not the group membership 
25 information. Each TAP manager issues multiple commands to the chain manager 1 06 to satisfy the 
TAP request for the physical processor it controls. 

As noted previously, the last command issued by a given TAP manager is a group scan 
command. After a group scan command is issued by a given TAP manager, the chain manager 106 
places the corresponding processor under test in a passive state, e.g., an IEEE 1 149.1 bypass state, 

6 
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until all group members have requested the group scan. In this passive state, the processor is 
generally not interacting with the scan chain. When all group members have requested the group 
scan, the chain manager 106 commences with the group scan, and then deallocates all group 
resources, effectively dissolving the group. The system user may select synchronous or 
5 asynchronous group control of the processor group for commands such as run, resume, step, step-n, 
halt, and halt at breakpoint. All knowledge of the processor-specific IEEE 1 149.1 interface for a 
given processor is contained in the corresponding TAP manager program. 

An operator of the system 1 00 of FIG. 1 , also referred to herein as a debug client, can utilize 
the control mechanism of the present invention to support different sets of semantics for multiple 
10 processors, such that commands (e.g., reset, start, step, halt, etc.) issued to a command window of 
a particular processor affect only that processor, while commands issued to a command window of 
kS a specified group of the processors affect all processors of the group simultaneously. 

!;L{ FIG. 2 illustrates in greater detail the above-described processing of test commands in the 

W FIG. 1 system. The figure shows sequences of individual scans 150X, 150Y and 150Z for each of 

in 1 5 the processors X, Y and Z, respectively, as a function of time. Associated with each of the sequences 
y of scans 15 OX, 150Y and 150Z are corresponding sets of passive IR and DR data 152X, 152Y and 

O 152Z, respectively. As is apparent from the figure, the individual scan sequences and associated 

ill passive data are each delivered to a particular processor. The figure also shows an example of a 

j;= group scan which includes two components: an IR scan involving IR data 154X, 154Y and 154Z, 

□ 20 and a DR scan involving DR data 156X, 156Y and 156Z. 

It should again be emphasized that the above-described control mechanism may be utilized 
in any type of multiple processor digital system, and is not limited to use with any particular number, 
type or arrangement of processors. An example of a multiple processor system in which the 
invention may be implemented is the TargetView™ system from Lucent Technologies 
25 Microelectronics Group of Allentown, Pennsylvania, 

A possible IEEE 1149.1 state sequence for a group scan of the type described above in 
conjunction with FIG. 1 is as follows: 
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Run-Test-Idle 

Select-Dr-Scan 

Select-Ir-Scan 

Capture-Ir 

Shift-Ir 

Exit 1 -It 

Update-Ir 

Select-Dr-Scan 

Capture-Dr 

Shift-Dr 

Exitl-Dr 

Update-Dr Type I processors begin interpreting DR data here 
Run-Test-Idle Type II processors begin interpreting IR data here 

Additional details regarding these states can be found in the above-cited IEEE 1149.1 
standard document. The notations Type I and Type II refer generally to different processor 
architectures, i.e., Type I is a first type of processor architecture and Type II is a second type of 
processor architecture. Thus, a group of processors which includes only Type I or Type II processors 
is a group of homogenous processors, while a group which includes both Type I and Type II 
processors is a group of heterogenous processors. 

Referring again to FIG. 2, the IR scan component of the group scan illustrated therein may 
be used, e.g., to prepare Type II processors for synchronous or pseudo-synchronous operation, or to 
select an appropriate DR for Type I processors. The DR scan component of the group scan of FIG. 
2 may be used, e.g., to synchronize Type I processors, such that when the processor TAP managers 
return to the Run-Test-Idle state all Type II devices are synchronized. 

Consider by way of example an arrangement in which the group of processors in the FIG. 
1 system consists of only homogeneous processors. In this example, synchronous control may be 
provided as follows: 
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GROUP-RUN Type I processors. 

Each processor is prepared for the final group command. 

When the last group member issues its group command, all physical processors 
simultaneously receive their group command at the IEEE 1149.1 UPDATE-DR state. Since all 
5 processors share a common IEEE 1 149.1 test clock, all processors start on the same clock edge. 

GROUP-RUN Type II processors. 

Each processor is prepared for the final group command. 

When the last group member issues its group command, all physical processors 
1 0 simultaneously receive their group command at the IEEE 1 1 49. 1 RUN-TEST-IDLE state. Since all 
processors share a common IEEE 1 149. 1 test clock, all processors start on the same clock edge. 

:;L; As another example, pseudo-synchronous control may be provided for a group of 

W heterogeneous devices in the FIG. 1 system as follows: 

^ GROUP-RUN Type I and Type II processors. 

□ Each processor is prepared for the final group command. 

)!j When the last group member issues its group command, one or more Type I processors 

O receive the group command at the IEEE 1 149.1 UPDATE-DR state. One IEEE 1 149.1 test clock 

O 20 cycle later at the IEEE 1 149. 1 RUN-TEST-IDLE state, the Type II processors in the group receive 
the group command. Each of the Type I processors thus operates on the same clock edge, while each 
of the Type II processors operates on the next clock edge. This is an example of the pseudo- 
synchronous control referred to herein. 

25 FIG. 3 illustrates the above-described control mechanism in greater detail. In the figure, the 

notation "1" signifies a single element, and "1 ..*" signifies one or more elements. For example, one 
scheduler schedules one or more TAP managers, and one JTAG chain manager receives JTAG 
commands from one or more TAP managers. 

9 
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In step 200 of FIG. 3, debugger 102 debugs programs in a processor by issuing debugger 
commands to one or more target hardware schedulers 104. Each debugger command identifies the 
TAP position of its processor. In step 202, the scheduler 104 forwards each debugger command to 
the specific TAP manager 108 requested by the debugger 102, It should be noted that there is one 
5 scheduler 104 per JTAG scan chain. 

As indicated in step 204, the scheduler 1 04 removes any non-zero GROUP ID that it receives 
with a debugger command before forwarding that debugger command to its corresponding TAP 
manager. The scheduler forwards the GROUP ED and TAP manager position to the JTAG chain 
manager 106. The chain manager 106 issues a JTAG command bit stream for a group scan 
1 0 associated with a non-zero GROUP ID only when all TAP managers in that group have issued their 
JTAG group scan commands. 

In step 206, each TAP manager translates debugger commands to JTAG commands for its 
];L[ processor. There is one TAP manager for each processor on a JTAG scan chain. In general, TAP 

managers for homogenous processors run identical translation programs, while TAP managers for 
in 15 heterogeneous processors run different translation programs. 

'"~ 4 Step 208 indicates that the chain manager 106 merges JTAG commands from each TAP 

O manager into one sequence of bits for the serial JTAG scan chain 1 10. The chain manager 106 

u\ defers issuing a JTAG group scan command that carries a non-zero GROUP ID until every TAP 

manager in that group has issued a JTAG group scan command. When the final TAP manager in 
p 20 a group issues a group scan command, the chain manager 106 uses a single, synchronous bit stream 
to issue commands to all processors on the scan chain that are in that group. 

In step 210, the hardware scan chain 1 10 carries JTAG commands as a serial, synchronous 
bit stream to processors connected to the chain. Step 212 indicates that each processor in the scan 
chain either interprets or ignores (e.g., bypasses) JTAG commands sent to that processor via the scan 
25 chain. There is a one-to-one correspondence between each processor and its TAP manager, but their 
electrical connection is via the JTAG scan chain 110. 

FIG. 4 shows a timing diagram of a group scan for an example usage scenario of the control 
mechanism of the present invention. In this example, it is assumed that debugger 102 issues a 
command to each of a group of TAP managers denoted TAP 0, TAP 1 and TAP N, corresponding 

10 
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to respective processors 0, 1 and N, using a single non-zero GROUP ID. Each TAP manager 
translates its debugger command into a sequence of JTAG commands, but the JTAG chain manager 
106 delays issuing the final group scan JTAG commands onto the JTAG hardware scan chain 110 
until the arrival of the final JTAG command for TAP N, i.e., the group scan command for TAP N. 
The JTAG chain manager then issues the JTAG group scan commands for processors 0, 1 and N on 
the scan chain as a single synchronous bit stream. As a result, initiation or termination of processor 
execution, or of any other processor operation controlled by JTAG commands, is synchronized or 
pseudo-synchronized for processors 0, 1 and N. In the figure, full arrows denote operations that 
execute when requested. Half arrows denote operations that the JTAG chain manager defers until 
all JTAG group scan commands for a specific non-zero GROUP ID have arrived at the JTAG chain 
manager. 

The JTAG chain manager 106 thus defers transmission of the JTAG command bit stream 
onto the JTAG hardware scan chain until the arrival of the final JTAG command for a group of 
processors with a shared GROUP ID. 

Advantageously, the control mechanism of the present invention may be implemented in 
software. The above-described control mechanism of the present invention allows dynamic 
formations of groups of processors with differing IEEE 1 149.1 TAP architectures, e.g., Type I or 
Type II architectures, so as to allow the processors to be controlled synchronously or pseudo- 
synchronously by a debug client. All mechanics of group control are handled in the illustrative 
embodiments by the chain manager so that the debug client can define the semantics of group 
interaction at run time. 

The above-described embodiments of the invention are intended to be illustrative only. 
Numerous other alternative embodiments may be devised by those skilled in the art without 
departing from the scope of the following claims. For example, the invention may be used to test 
digital systems which are implemented in software and downloaded into a set of hardware which is 
known to be operating correctly. These and other alternative embodiments will be readily apparent 
to those skilled in the art. 
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